Loading the "Reorder Pages" space tool page for very large spaces as a non site-admin user causes CPU spike

If you have a space that is large (tested and confirmed with a single space with 20,000 pages), going to the "Reorder Pages" space tool page causes a sustained CPU spike. This can cause performance issues on the Confluence node that you're on.

Steps to Reproduce

• Generate a space with 20,000 pages or more (testing notes are placed into an internal comment)
• As an site admin user, restrict view/edit of an arbitrary set of pages in the space
• Create a user with basic permissions
• In a new browser session, login to Confluence with this new user's credentials and go to the space and go to the Space Tools cog > "Reorder Pages".
• The expected page tree won't be displayed on the page, but a spinning wheel icon will be shown on the Reorder Pages tab instead.
   The same issue is also being observed should the space-admin user performs the same steps. 

Diagnosis

• In thread dumps, calls to the "children.action" endpoint will show up in thread dumps if you have Thready installed. This corresponds to the same process IDs that have the highest CPU usage.
• The threads will eventually clear and complete the action (unclear if the action times out and the end user gives up or if it actually renders). Thus, it will show as a big spike that can cause alerting platforms to send out warning alarms outside of normal baseline.
• It's not clear if this can actually cause an outage or not. All tests thus far have been on an AWS m4.4xlarge instance with 16 GB of JVM heap and no active users.
• We saw this take place multiple times for an Enterprise customer that caused concern, but no outages resulted as part of this action.

Performance Points

• Accessing the "Reorder Pages" space tool can be done by any user that has access to the space. Even users who are unable to edit pages in a space and have only View rights can still go to the page and trigger the same calls.
• These calls appear to go to the database directly instead of to cache or an index of some kind. In other words, it uses an expensive method to retrieve the data it needs.
• By itself, this likely will not cause outages, but if there are several large spaces or specific users attempting to access the same tool at the same time, it could potentially kick off multiple threads.
• This seems to be more of a scaling issue than anything - smaller spaces don't actually seem to encounter this issue at all.